IBIS Macromodel Task Group Meeting date: 22 September 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai * Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad to update the draft of the Info, Out, InOut BIRD. - Done (revision #12 posted on the ATM website). - Mike L. to add a ver6_1_known_issues.txt to the 6.1 spec folder and add the issue Arpad discovered ("General Reserved Parameters" section number). - Done. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L: Motion to approve the minutes. - Todd: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Item #6: Info, Out, InOut BIRD draft. - Arpad: [sharing and reviewing the newly posted revision #12] - Name of the parameter changed to NonStandardParams. - New "Other Notes" section. - Other Notes: A non-standard Model_Specific parameter may require action from the user or the EDA tool that is not described in the IBIS specification. - Bob R: Add the Info, Out, InOut to the Other Notes text to fully describe what parameters' Usage(s) might be non-standard. - Walter: Why doesn't it include Usage In? - Arpad: In goes from the AMI file to the model. - Walter: That's not necessarily true. It is also available for use by the EDA tool. - Todd: This is a voluntary declaration of something as non-standard. - Therefore, we shouldn't assume the degree of non-standard-ness. - Arpad: Okay, then this BIRD is open to all Usage(s). - Bob R: I prefer NonSpecified to NonStandard. A parameter could comply with the specification but expect the tool or user to modify the parameter in a non-specified way. - Radek: The issue is only whether any special action should be taken by the tool based on the value of such a parameter. - Bob R: This is a specification, it may become a standard but it's not a standard yet. - It's really a non-specified action we are talking about. - Mike L: If we're making an important distinction, any one of our specifications could become standards. - Radek: The only things specified are Reserved Parameters. - Anything in the Model Specific section is not specified by the specification. - So by this definition everything in Model Specific would be unspecified. - I think NonStandard is closer to the meaning we want. - Bob M: I think the crux of this issue is also with the Other Notes statement. - I think it should not include the words "from the user". - Model vendors may have plenty of parameters that require the user to set them appropriately in order to get useful results from the model. - The key is whether the EDA tool directly interacts with the parameter. - For example, a "tuning mode" parameter that allows the user to select the value does not require special handling. - Discussion: What is NonStandard (or NonSpecified)? Bob R.'s initial comments about nonstandard vs. nonspecific led to a discussion that revealed a more fundamental difference of opinion on this BIRD. Bob M.'s example (Model Specific "tuning" parameter of Usage In, Format Table, Type String, from which the user would select a value) served to highlight the difference. Bob M., Radek, John, Todd, and Curtis all supported the interpretation that such a parameter would not need to be listed in the new NonStandardParams. It was an acceptable use of a Model Specific parameter and would classify as "normal processing." Since only the user was making the selection, and the EDA too was not doing anything with the parameter on its own, nothing was NonStandard. Any EDA tool should be able to present the user with the list of choices. Bob R. contended that such a parameter should be listed in the new NonStandardParams because its behavior was not defined in the specification. Others (see Radek above) felt that this interpretation would then apply to all Model Specific parameters, rendering the new NonStandardParams meaningless. Throughout the discussion Arpad tracked various proposed changes in the language of the BIRD for use in a future revision. - Discussion: Using Reserved Parameters. Todd brought up a suggestion he had previously made. One might list the non- standard params under Reserved Parameters (since they require some special handling that needs to be defined eventually), but also list them under the new NonStandardParams so that the parser would know not to issue errors when it found Reserved Params it didn't recognize. This would let the user know what params expected special handling from the EDA tool (those in Reserved), but which ones weren't defined in the spec (NonStandadParams). Bob R. again opposed this concept. Arpad pointed out that the current definition of Reserved Parameters was that it included only things fully defined by the spec. - Discussion: Tstone models as an example. The tstone models were brought up as an example of special handling. The tstone parameter would need to be listed in the NonStandardParams. The tstone models also contain documentation listing workarounds the user might employ when using a tool that does not support the non-standard tstone (for example, manually including the touchstone model directly in the circuit). This was noted as a good thing to do in the case of non-standard parameters. - Bob R: Anyone can use the name 'tstone.' - Radek: That's a good example. - You may have a tstone parameter that should be completely ignored by the EDA tool. It may be used by the .dll to find the file and do something with the data, for example. - Therefore this NonStandardParams that lists those params that actually require special handling by the EDA tool is useful in differentiating between the two cases. - Bob M: That's the first time I've heard a really good reason for having a table of the non-standard parameters. - A model may use the same name in Model Specific quite by accident, but if it's present in the table the EDA tool knows something odd is going on with it. - Mike L: It's important to make sure that model makers will have a consistent understanding of whether a parameter falls under this BIRD or not. - Arpad: Thank you all for joining. AR: Arpad to work on next revision based on language changes proposed during the discussion. ------------- Next meeting: 29 September 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives